Structuring

Introduction

Structuring is the core skill which is tested as a part of the consulting case interview. It is also one of the most useful skills to have as a consultant, or really in almost any corporate job. Structuring and communication are comprehensively, really all of the building blocks needed to a top individual perform in a corporate. The idea of structuring is to take a complex and large problem (as one often has) and to break it into smaller, more solvable parts. Importantly the parts must make up the whole, meaning that answering the smaller questions should necessarily lead to an answer to the original question.

MECE

You will hear this phrase thrown around a lot. And honestly, it's a little fun to throw it around on your own. This is the key deciding factor as to whether your structure is good or not. Your structure should be:

- Mutually Exclusive -

There should be no overlap between one subpart and another.

- Cumulatively/Collectively Exhaustive -

The different subparts together should make up the whole.

In practise, a lot of structures will miss out on some fringe cases, and may have some degree of overlap, which can be removed with some simple assumptions. Those structures can still be workable. Better structures aren't very difficult to aim for, and you should therefore aim for your structure to be perfectly MECE, because fun cases are often built on fringe cases.
Another key requirement is for your structure to be simple. Once again, we would like to aim for structures which have <=3 subparts. Sometimes that isn't possible. As long as the structure remains simple to understand and use, like a 4Ps framework, it's okay if this number is breached slightly. However, if you find yourself using a structure with 6+ subparts, you would probably be better served by grouping some parts together, and breaking them into the required 6+ subparts on a need to do basis.

How

What makes structuring challenging are the roadblocks that you will run up against. While structuring a problem, you might face one of the following doubts/problems:
- Is this exhaustive?
- Some buckets overlap.
- Is this the most simple/elegant way of structuring it?
- It's MECE, but are each of the smaller problems solvable?
- How can I possibly break this question down?
In a short period of time (~30s) it can be difficult to successfully come up with a structure, then address these doubts and then build the confidence in your structure required to say it out loud. So the first step that one should take is to become good at structuring when you have ample time. Keep taking up questions to structure, and then subject it to the above 5 questions, until you have better structures, which are more usable. At some point you might find that you have a good structure for most of the questions that you come up with already. That is not the goal. That means your questions lack creativity. The goal is to make sure that you have a good process for any type of question that you encounter, so that you can come up with a good new structure, even if non of your regular structures fit.

Approaches

When I started structuring problems I used to think about what are the parts that make this problem up, or what are the levers. Eventually I got comfortable with thinking through this faster. Some questions still wouldn't be easily addressed through this line of thinking, but I somehow intuitively got better at addressing those. When I looked at a bunch of my favourite frameworks, it occurred to me that this approach was subpar. What I do now believe to be a good approach to structuring is as follows:
1. Classify the problem on the basis of the required output.
2. Basis the classification, ask the right kind of question, to break it down (method of structuring).
3. Any good answer, to the right kind of question will be a good structure to address the problem.
The key challenge in structuring is to therefore classify the problem and ask the right kind of question. From there on out, you should be able to easily answer, and present your structure. So what are the different types of problems?

- Problem Spotting

  - Numeric (lower/higher than expected) -
    - Method of structuring - Create a formula which equals the number in question
    - Examples - Contain shorthand. If you can't understand some of them, try structuring it on your own.

  - Process(to be studied/accomplished) -
    - Method of structuring - Map out the customer journey (or the journey of the relevant stakeholder)
    - Examples - Contain shorthand. If you can't understand some of them, try structuring it on your own.

  - Qualitative Analysis(identifying problem/strength) -
    - Method of structuring - Identify the stakeholders/properties/assets of the subject being analysed
    - Examples - Contain shorthand. If you can't understand some of them, try structuring it on your own.

- Solution Defining

  - Task(to be done/studied) -
    - Method of structuring - Split the tasks/activities into 3 categories (representing internal, neighbourhood and external)
    - Examples - Contain shorthand. If you can't understand some of them, try structuring it on your own.

  - Select an Alternative(which option is best) -
    - Method of structuring - On a case to case basis, list out the alternatives which exist (in this case exhaustive options should be apparent)
    - Examples - Contain shorthand. If you can't understand some of them, try structuring it on your own.

While the above framework lays out a useful approach to quickly structure a problem in an actionable manner, it is not a hard and fast rule for 2 reasons:
1. The above framework itself isn't MECE, so problems will lie across multiple areas above.
2. Even when a problem lies specifically in one problem area, an approach of a different type might prove to be better.
So what do we do? We continue to use the above framework for the most part, because the majority of the time, it will give us the best way of approaching a problem, and will even otherwise give us a good approach. With practise, you will form your own preferences, exceptions to the above framework, and will hopefully refine it, so that you have a better approach to structuring than I do.

Takeaway

Just keep practicing and have fun with structuring. If you're discussing a hypothetical with friends, or you see a news article, just try structuring the problem. Push yourself to structure problems that seem open ended. In doing so you'll get to test out a wide range of scenarios, and improve upon and customise the above approach to something that you own and are more comfortable with.